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BINDING INFORMATION FOR IP MEDIA FLOWS 

RELATED APPLICATION INFORMATION 

The present application claims the benefit of U.S. Provisional Patent 
5 Application Serial No. 60/284,358, entitled "Binding Information for IP Media Flows," 
filed April 17, 2001, the disclosure of which is incorporated by reference. 

■ 

TECHNICAL FIELD 

The present invention relates to a binding mechanism for packet media 
10 flows. In one embodiment, the binding mechanism uses an authorization token and 
one or more flow identifiers to identify one or more media flows of a session for 
authorization. 

BACKGROUND 

15 In the last ten years, the number of cellular devices used by the public has 

exploded. Mobile telephones are commonplace, and personal digital assistants 
["PDAs"] and laptop computers with wireless capability are increasingly popular. 
Cellular devices are used for browsing the World Wide Web, one-way and two-way 
audio and video communication, instant messaging, and transmitting and receiving 

20 other types of multimedia information as well. 

Over the same period, the Internet has grown tremendously. In the early 
1990's, the Internet was typically used for email, text communication, or file 
transfer. Today, the Internet is still used for these purposes, but it is also used for 
one-way audio and video streaming, two-way audio and video communication, 

25 multimedia browsing, and messaging. 

The Internet is an example of a packet-switched network. Whatever kind of 
information is sent over the Internet, the information is transmitted in packets. In 
general, a packet has 1) a header with addresses of the sender and destination for 
the packet and 2) a data payload portion with a chunk of the information. Packets 

30 are routed from computer to computer within the Internet to get from the sender to 
the destination. Internet Protocol ["IP"] is a set of rules for transmitting packets over 
the Internet. Various versions of IP have been developed, as have other packet 
data protocols. 
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The Internet offers several advantages as a telecommunications network. It 
spans the globe and includes redundancy to compensate for equipment failure. It 
operates with a variety of different types of networks and end user equipment. 

On the other hand, several traits of the Internet make it unsuitable for certain 
5 applications. Conventionally, delivery of packets over the Internet happens 

according to a best effort model. A routing computer (i.e., router) routes packets as 
best it can, but sometimes gets overwhelmed with the amount of traffic. At such 
times, delivery of packets can be delayed or packets can get dropped. For 
applications such as email this is not really a problem, because delivery time is not 

1 0 critical and packets can be re-transmitted. For other applications, however, delay 
and discontinuity are more problematic. Audio telephony and videoconferencing 
have limits on the amount of delay that is acceptable for communication. Audio and 
video streaming have less stringent limits, but also can suffer from delay and 
discontinuity. The best effort model of the Internet hinders the development of 

1 5 audio, video, and other IP multimedia applications that have higher quality of 

service ["QoS"] requirements. In addition, Internet users are typically charged a flat 
access fee unrelated to how many packets the user transmits or receives over the 
Internet. People using the Internet for email can thus be charged disproportionately 
compared to people using the Internet for IP multimedia applications. Moreover, 

20 people who would pay more for higher QoS do not have that option. 

Some recent developments have focused on how to take advantage of the 
good features of the Internet while addressing the traits that make it unsuitable for 
applications with higher QoS requirements. Other developments have focused on 
QoS in mobile telecommunications networks and end-to-end QoS for devices that 

25 communicate across both mobile telecommunications and packet-switched 
networks. 

I. Session Initiation and Description Protocols 

Session Initiation Protocol ["SIP"] is a set of rules for creating, modifying and 
30 terminating sessions with one or more participants. These sessions include 
Internet multimedia conferences, Internet telephone calls and multimedia 
distribution. SIP is mainly used for signaling information about sessions, and 
operates on top of lower-level protocols that control things such as routing of 
packets. 
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A SIP message can carry a session description, for example, according to 
Session Description Protocol ["SDP"], which allows participants to agree about the 
media flows for the session. A SDP description includes a session-level description 
(with details that apply to the session and the media streams) and zero or more 
5 media-level descriptions (with details that apply to a single media stream). The 
session-level description includes information like session name (identified by a line 
beginning with "s- ' in the SDP description), and can also include connection 
information ("c="), bandwidth information ("b="), and other information. A media- 
level description ("m=") includes information such as media type (e.g., video, 
1 0 audio), transport protocol, and format (e.g., MPEG video). A media-level 

description can also include connection information, bandwidth information, and 
other information. 

SIP supports user mobility by proxying and redirecting requests to the user's 
current location. For example, a user can register his current location with a SIP 
1 5 proxy, which acts as an intermediary for the user for SIP signalling. 

SIP has been extended to support call authorization using user agents 
["UAs"] and SIP proxies. UAs (e.g., cellular devices of users) are considered 
untrusted. For a UA-initiated call, a SIP proxy authorizes media data to/from the 
UA. The SIP proxy supplies a media authorization token to the UA. When the UA 
20 is ready to exchange a media data with another endpoint, the UA requests 
bandwidth using the media authorization token it received from its SIP proxy. 

For more information about SIP and SDP, see Request for Comment 
["RFC"] 2543 and RFC 2327 from the Internet Engineering Task Force ["IETF"]. 
For the SIP extension described above, see the IETF Internet Draft entitled "SIP 
25 Extensions for Media Authorization," version 1 . 

II. Next Generation Internet Architectures 

To address concerns with QoS over the Internet, various architectures have 
been researched which change the traditional best effort model of the Internet. 
30 These next generation architectures include the Integrated Services in the Internet 
Architecture ["IntServ"] and the Architecture for Differentiated Services ["DiffServ"]. 

IntServ defines a set of extensions to the traditional best effort model of the 
Internet. In the IntServ architecture, a setup mechanism is used to convey 
information to routers so that the routers can provide requested services to flows 
35 that require the sen/ices. Resource Reservation Protocol ["RSVP"] is one setup 
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mechanism. With RSVP, a host requests a specific QoS from the network for a 
particular data flow. The network responds by admitting or rejecting the request. 
For admitted requests, the appropriate routers are configured to provide the QoS. 
For additional information about IntServ and RSVP, see RFC 1633, RFC 2205, and 
5 related specifications. 

In the DiffServ architecture, packets are classified into one of multiple 
aggregated flows or "classes." A packet header includes a DiffServ codepoint 
[ K DSCP"] indicating the class of the packet. A network node at the edge of the 
DiffServ network (i.e., a DiffServ edge node) can place an appropriate DSCP in the 
1 0 packet header. Based on the DSCP, a DiffServ router can apply different packet 
forwarding treatment to the packet for the next hop in the DiffServ network. For 
additional information about DiffServ, see RFC 2474, RFC 2475, and related 
specifications. 

To address concerns about charging for Internet usage, various 
1 5 authorization and charging architectures have been explored. Different 

architectures charge by Internet usage (e.g., traffic and/or connection time), mobile 
telecommunications network usage, session or media flow. In various applications, 
charging by session and flow offers the advantages of simplicity to the end user and 
flexibility in pricing packages for different networks. For additional information, see 
20 the relevant specifications by the IETF and the 3 rd Generation Partnership Project 
["3GPP"]. 

III. End-to-End QoS 

When information flows over the Internet between two cellular devices, end- 
25 to-end QoS can depend on the Internet QoS as well as the QoS for the mobile 
telecommunications networks (e.g., Global System for Mobile Communication 
["GSM"] or Universal Mobile Telecommunications System ["UMTS"] network) 
between the Internet and the cellular devices. 

The 3GPP has organized numerous specifications relating to mobile 
30 telecommunications networks QoS and end-to-end QoS. 3 rd Generation Technical 
Specification ["3G TS'l 23.060 v3.6.0 describes packet services that use a Packet 
Data Protocol ["PDP'l like IP over a mobile telecommunications network. 3G TS 
23.107 V4.0.0 describes a QoS framework for UMTS networks. 3G TS 23.207 
v1 .2.0 describes a framework for end-to-end QoS and adresses how to map QoS 
35 requirements between different networks. 
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A. Bearer Services 

In general, to realize a certain QoS over a network, a bearer sen/ice ["BS," 
. "bearer," or "service"] with defined characteristics and functionality is set up from 
5 the source to the destination of the service over the network. A bearer service 

includes aspects that enable the provision of a contracted QoS, for example, control 
signalling, user plane transport, and QoS management functionality. Figure 1 
shows a bearer service layered architecture (100) according to the prior art. A 
bearer service on a specific layer uses services provided by the layers below and 
1 0 offers services to the layers above. Other architectures lack one or more of the 

services shown in Figure 1 , use a different configuration of services, or use different 
services. For additional information about Figure 1 and the services and 
components referenced therein, see 3G TS 23.207 v1.2.0, 3G TS 23.107 V4.0.0, 
and related specifications. 

15 

B. Example Network Architecture 

Figure 2 shows a simplified example of a network architecture (200) 
according to the prior art. Other network architectures are possible. The 
architecture (200) includes a UMTS network using a general packet radio service 
20 ["GPRS"] and a backbone IP network (240) (e.g., the Internet). 

In Figure 2, the local user equipment ["UE"] (210) is, for example, a cellular 
device such as a mobile telephone or computer with wireless transmission 
. capability. The serving GPRS support node ["SGSN"] (220) and the gateway 
GPRS support node ["GGSN"] (230) contain functionality to support GPRS for 
25 mobile telecommunications networks, and can be in the same or different network 
nodes. The SGSN (220) communicates, for example, by wireline channel with a 
base station that in turn communicates by radio transmission with the UE (210). 
The GGSN (230) routes packets (e.g., providing DiffServ Edge, IntServ/RSVP 
signaling, or other functions) between the UMTS network and the backbone IP 
30 network (240). 

The IP Bearer Layer (270) includes an IP Bearer Service (272) for providing 
a contracted QoS from the UE (210) to the remote host (260), spanning the UMTS 
network and the backbone IP network (240). The Access Bearer Layer (280) 
includes bearer services underneath the IP Bearer Layer (270), for example, a 
35 UMTS Bearer Service for providing a contracted QoS between the UE (210) and 
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the GGSN (230). Figure 2 abstracts away the details of the remote access point 
(250) and access bearer service between the backbone IP network (240) and the 
remote host (260), which can mirror the UE (210) side or be different. 

The UE (210) has one or more PDP (e.g., IP) addresses, which can be 
5 statically or dynamically assigned. One or more PDP contexts are set up across 
the PDP context bearer (e.g., the GPRS over the UMTS network). For example, 
with a PDP Context Activation request, the UE (210) requests a packet service with 
a specified QoS for a PDP address from a Access Point Name ["APN"]. The APN 
refers to an external packet data network and/or a service, and can be used in 
1 0 mapping the request to a GGSN. The requested QoS can be specified with a QoS . 
profile. 

A QoS profile is a set of attributes specifying the service for a network such 
as a UMTS network. 3G TS 23.107 v4.0.0 describes four different UMTS QoS 
traffic classes, which differ mainly in how delay sensitive the traffic is. In addition to 
1 5 traffic class, a user of the bearer can specify other attributes for the service 
provided by the network, including maximum bitrate, guaranteed bitrate, and 
transfer delay. 



Class 


Intended Use 


conversational 


Very delay-sensitive traffic such as audio and video telephony. 


streaming 


Non-conversational traffic, which are less delay-sensitive than audio 
and video telephony. 


interactive 


Interactive applications like WWW browsing and instant messaging. 


background 


Delay-insensitive traffic such as background file or email downloading. 



Table 1 : UMTS QoS traffic classes in TS 23.107 v4.0.0 

20 

The SGSN (220) and the GGSN (230) can modify the requested QoS 
according to a subscriber profile, current resources, or other criteria. The UE (210) 
can request additional PDP contexts at the same or different QoS over the PDP 
context bearer. The UE (210) can also modify certain attributes of existing PDP 

25 contexts (e.g., with a PDP Context Modification request). In some circumstances, 
the GGSN or other network entities can activate or modify contexts. 

For additional information about Figure 2, the service and components 
referenced therein, other network architectures, PDP, QoS profiles, and QoS for 
UMTS networks, see 3G TS 23.207 v1 .2.0, 3G TS 23.107 v4.0.0, 3G TS 23.060 

30 V3.6.0, and related specifications. 
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C. Policy Enforcement and QoS Inter-Working 

Figure 3 shows a framework (300) with QoS management functions for end- 
to-end IP QoS according to the prior art. At a high level, Figure 3 shows UE (310), 
a UTRAN (320) such as a network of cellular base stations, a CN EDGE (330) such 
5 as a SGSN, a gateway (340) such as a GGSN, a proxy - call session control 
function ["P-CSCF"] (350), and an external network (360). For the sake of 
simplicity, Figure 3 does not show lower layer bearer service functions. 

In Figure 3, the gateway (340) includes an IP BS manager (342), a 
translation (346) function, and a UMTS BS manager (348). The IP BS manager 
1 0 (342) manages the inter-working with the external network (360), using 

mechanisms such as DiffServ Edge, RSVP/lntServ signaling, policy control, or 
service agreement functions. The IP BS manager (342) communicates with the 
UMTS BS manager (348) through the translation (346) function, which provides the 
inter-working between the mechanisms and parameters (e.g., QoS parameters) of 
1 5 the UMTS bearer service and those of the IP bearer service. Other frameworks are 
possible, for example, those including an IP BS manager and translation function in 
the UE (310), or those using other mechanisms for inter-working between networks. 
The framework (300) can be used for policy-based admission control, in 

« 

which a policy control function ["PCF"] (353) makes decisions in regard to network- 
20 based IP policy using policy information and rules. Policy information elements 
include, for example, addresses and authorized QoS for the IP flows of a session. 
The PCF (353) communicates policy information to the IP BS manager (342) in the 
gateway (340) across an interface. For IP Multimedia and other services, service- 
based local policy ["SBLP"] decisions can be applied to a bearer. SBLP decisions 
25 involve interaction between the UE(310), the gateway (340), and the P-CSCF (350). 
. In addition to the PCF (353), the P-CSCF (350) includes a local SIP proxy 
(351), which is used for SIP signaling and obtaining a SDP description of a session. 
The P-CSCF (350) and PCF(353) have several roles, including authorizing QoS 
resources for the session described in the SDP description. The P-CSCF 
30 (350)/PCF (353) can generate an authorization token for a SIP session and send 
the authorization token to the UE (310) by SIP message. The authorization token, 
for example, conforms to the IETF specification on SIP Extensions for Media 
Authorization. 

The UE (310) makes resource reservation requests that the gateway (340) 
35 matches with authorizations from the PCF (353). For example, the UE (310) 
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includes the authorization token in PDP Context Activation or Modification requests 
along with UMTS QoS parameters. The authorization token can then be used to 
correlate the requests with the authorizations from the PCF (353). 

The gateway (340) is the IP policy enforcement point and has several roles. 
5 It controls acess to QoS for flow(s) of IP packets. Policy information is either 
"pushed" to the gateway (340)' by the PCF (353) or requested from the PCF (353) 
by the gateway (340). The gateway (340) also provides flow control/gating 
functionality, and takes action when the IP packets for a flow exceed authorization. 
For additional information about Figure 3 and the service and components 
1 0 referenced therein, see 3G TS 23.207 v1 .2.0 and related specifications. 

In general, per-flow authorization gives finer control over authorization, QoS 
management, and charging than per-session authorization, which in turn has 
advantages compared to network-level authorization alone. The authorization 
token generated during SIP signaling, however, is inadeqaute for individually 
1 5 identifying multiple different flows of a session for authorization. 

SUMMARY 

The present invention relates to a binding mechanism for packet media 
flows. The binding mechanism uses an authorization token and packet media flow 

20 identifiers to identify packet media flows of a session for authorization. This 
provides the advantages of using a per-session authorization token while also 
allowing resource authorization and allocation on the basis of individual packet 
media flows of the session. The binding mechanism includes various aspects. 

According to a first aspect, an apparatus transmits one or more messages 

25 including binding information for authorizing one or more packet media flows of a 
session. The binding information includes an authorization token that, when 
combined with a packet media flow identifier, is sufficient to identify a packet media 
flow of the session. For example, a UE transmits one or more PDP context 
requests including binding information. The binding information includes a SIP 

30 media authorization token and one or more IP media flow identifiers. 

According to a second aspect, a network node processes binding 
information for authorizing one or more packet media flows of a session. The 
binding information includes an authorization token. The network node interprets 
each of one or more packet media flow identifiers relative to the authorization token 
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to identify a packet media flow of the session. For example, binding information 
includes a SIP media authorization token and one or more IP media flow identifiers. 
Additional features and advantages of the invention will be made apparent 
. from the following detailed description of described embodiments that proceeds 
5 with reference to the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a diagram of a bearer service layered architecture according to 
the prior art. 

1 0 Figure 2 is a diagram of a simplified example of a network architecture 

according to the prior art. 

Figure 3 is a diagram illustrating QoS management functions for end-to-end 
IP QoS according to the prior art. 

Figure 4 is a block diagram of a suitable computing environment in which 
1 5 described embodiments may be implemented. 

A 

Figures 5 and 6 are flowcharts of techniques for a binding mechanism using 
an authorization token and IP media flow identifier(s). 

DETAILED DESCRIPTION 

20 Described embodiments of the present invention are directed to a binding 

mechanism for authorizing QoS requested for one or more IP media flows of a 
session. Binding information transmitted from UE to a GGSN includes a SIP media 
authorization token. The GGSN interprets one or more IP media flow identifiers 
relative to the SIP media authorization token to identify the one or more IP media 

25 flows of the session. In terms of transmission bandwidth, computational complexity, 
and signaling complexity, using a per-session authorization token is more efficient 
than using a different authorization token per IP media flow of the session. At the 
same time, using multiple IP media flow identifiers in conjunction with the per- 
session authorization token provides a simple mechanism for resource 

30 authorization and allocation on the basis of individual IP media flows of the session. 

In the described embodiments, the binding mechanism includes several 
techniques and systems. While the techniques and systems are typically described 
herein as part of a single, integrated framework, the techniques and systems can 
be applied separately, potentially in combination with other techniques and 

35 systems. 
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In the described embodiments, the binding mechanism is part of a system 
that complies with a variety of technical specifications, including most notably 3G 
TS 23.207, but also including 3G TS 23.107, 3G TS 23.060, and the IETF Internet 
Draft entitled "SIP Extensions for Media Authorization." In alternative embodiments, 
5 the binding mechanism works in other systems and/or with other protocols. 

Table 2 lists some acronyms and abbreviations used in the present 
application. 



Short Form 


Full Term 


3G TS 


3 Generation Technical Specification 


3GPP 


3 rd Generation Partnership Project 


APN 


Access Point Name 


BS 


Bearer Service 


DiffServ 


Architecture for Differentiated Services 


DSCP 


DiffServ Codepoint 


GGSN 


Gateway GPRS Support Node 


GPRS 


General Packet Radio Service 


GSM 


Global System for Mobile Communication 


IETF 


Internet Engineering Task Force 


IntServ 


Integrated Services in the Internet Architecture 


IP 


Internet Protocol 


P-CSCF 


Proxy - Call Session Control Function 


PCF 


Policy Control Function 


PDA 


Personal Digital Assistant 


PDP 


Packet Data Protocol 


QoS 


Quality of Service 


RFC 


Request for Comment 


RSVP 


Resource Reservation Protocol 


SBLP 


Service-based Local Policy 


SDP 


Session Description Protocol 


SGSN 


Serving GPRS Support Node 


SIP 


Session Initiation Protocol 


UA 


User Agent 


UE 


User Equipment 


UMTS 


Universal Mobile Telecommunications System 


UTRAN 


UMTS Terrestrial Radio Access Network 



Table 2: Acronyms and abbreviations 

10 

I. Computing Environment 

Figure 4 illustrates a generalized example of a suitable computing 
environment (400) in which the described embodiments may be implemented. The 
computing environment (400) is not intended to suggest any limitation as to scope 
1 5 of use or functionality of the invention. The present invention may be implemented 
in diverse general-purpose or special-purpose computing environments such as 
cellular devices or other user equipment, or GGSN or other network nodes. 
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With reference to Figure 4, the computing environment (400) includes at 
least one processing unit (410) and memory (420). In Figure 4, this most basic 
configuration (430) is included within a dashed line. The processing unit (410) 
executes computer-executable instructions and may be a real or a virtual 
5 processor. In a multi-processing system, multiple processing units execute 

computer-executable instructions to increase processing power. The memory (420) 
may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., 
ROM, EEPROM, flash memory, etc.), or some combination of the two. The 
memory (420) stores software (480) implementing the binding mechanism with an 

1 0 authorization token and flow identifier(s). 

A computing environment may have additional features. For example, the 
computing environment (400) includes storage (440), one or more input devices 
(450), one or more output devices (260), and one or more communication 
connections (470). An interconnection mechanism (not shown) such as a bus, 

1 5 controller, or network interconnects the components of the computing environment 
(400). Typically, operating system software (not shown) provides an operating 
environment for other software executing in the computing environment (400), and 
coordinates activities of the components of the computing environment (400). 
The storage (440) may be removable or non-removable, and includes 

20 magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any 
other medium which can be used to store information and which can be accessed 
within the computing environment (400). The storage (440) may store computer- 
executable instructions for the software (480) implementing the binding mechanism 
with an authorization token and flow identifier(s). 

25 The input device(s) (450) may be a touch input device such as a numerical 

keypad, keyboard, mouse, pen, or trackball, a voice input device, a scanning 
device, or another device that provides input to the computing environment (400). 
The output device(s) (460) may be a display, printer, speaker, CD-writer, or another 
device that provides output from the computing environment (400). 

30 The communication connection(s) (470) enable communication over a 

communication medium to another computing entity. The communication medium 
conveys information such as computer-executable instructions, audio or video 
information, or other data in a modulated data signal. A modulated data signal is a 
signal that has one or more of its characteristics set or changed in such a manner 

35 as to encode information in the signal. By way of example, and not limitation, 
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communication media include wired or wireless media implemented with a radio 
frequency, electrical, optical, infrared, acoustic, or other carrier. 

The invention can be described in the general context of computer-readable 
media. Computer-readable media are any available media that can be accessed 
5 within a computing environment. By way of example, and not limitation, with the 
computing environment (400), computer-readable media include memory (420), 
storage (440), communication media, and combinations of any of the above. 

The invention can be described in the general context of computer- 
executable instructions, such as those included in program modules, being 

1 0 executed in a computing environment on a target real or virtual processor. 

Generally, program modules include routines, programs, libraries, objects, classes, 
components, data structures, etc. that perform particular tasks or implement 
particular abstract data types. The functionality of the program modules may be 
combined or split between program modules as desired in various embodiments. 

1 5 Computer-executable instructions for program modules may be executed within a 
local or distributed computing environment. 

For the sake of presentation, the detailed description uses terms like 
"request," "generate," and "modify" to describe computer operations in a computing 
environment. These terms are high-level abstractions for operations performed by 

20 a computer, and should not be confused with acts performed by a human being. 
The actual computer operations corresponding to these terms vary depending on 
implementation. 

II. Binding Mechanism 

25 A binding mechanism described herein associates a PDP context bearer 

with policy information in a GGSN to support SBLP enforcement and QoS inter- 
working. The policy information in the GGSN is based on IP media flows. The 
binding mechanism identifies the IP media flow(s) associated with a PDP context 
bearer and uses this identification information in selecting the policy information to 

30 apply. 

For the binding mechanism, binding information (e.g., an authorization token 
and flow identifier(s)) provided by a UE is sufficient to identify the IP media flow(s) 
carried on a PDP context. The binding mechanism provides a simple mechanism 
that allows for resource authorization and allocation on the basis of IP media flows 
35 while retaining a single authorization token in SIP signaling and PDP context 
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activation/modification messages. This achieves the advantages of using a single 
per-session authorization token and the advantages of per-flow resource 
authorization and allocation. 

For the policy information, for example, the P-CSCF/PCF uses an SDP 
5 description of a session to calculate authorization for the session, including 

restrictions on IP resources, IP packet flows, and (potentially) IP destinations. An 
authorized session may include one or more flow authorizations, with each flow 
authorization containing an IP flow 5-tuple (i.e., source address and port, 
destination address and port, protocol) for the flow, a specification of authorized 

1 0 resources for the flow, and a DSCP that identifies an assigned DiffServ per hop 
behavior for the flow. 

IP policy enforcement is based on IP media flows, while UMTS bearers are 
based on PDP contexts from a UE to a GGSN. When a PDP context is activated or 
modified and SBLP is in effect, the GGSN uses policy information associated with 

1 5 IP media flows to authorize the bearer. The UE controls the mapping of IP media 
flows to PDP contexts, and the UE provides the GGSN with binding information to 
allow it to correctly identify the policy information for PDP context 
activation/modification request messages. Otherwise, the GGSN will not have 
sufficient information to identify the policy information needed to authorize the 

20 bearer. 

The IETF SIP Working Group has considered using an authorization token 
per IP media flow in an SDP description, which could then be provided by the UE to 
the GGSN as binding information. While architecturally correct, this approach 
requires changing SDP and sending more information between the PCF, GGSN, 
25 and UE. 

In contrast, for the binding mechanism described herein, IP media flows are 
identified by their order in an SDP description. For example, the first media flow 
(identified by a line beginning with "m=" in the SDP description) is flow 1, the 
second media flow is flow 2, etc. Since both the P-CSCF/PCF and UE have the 
30 SDP description, they will identify flows in a consistent manner. Authorization 
information from the P-CSCF/PCF and binding information from the UE can both 
identify the media flow or flows. 

Figures 5 and 6 show techniques (500, 600) for a binding mechanism using 
an authorization token and IP media flow identifier(s). Figures 5 and 6 generally 
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illustrate the timing for the binding mechanism; the actual timing depends on the 
underlying protocols (e.g., SIP and PDP), network, etc. 

With reference to Figures 5 and 6, during SIP signaling, the P-CSCF/PCF 
transmits (610) an authorization token and SDP description to the UE. The UE 
5 receives (510) the authorization token and SDP description. 

The UE then transmits (520) a PDP context request. When activating/ 
modifying a PDP context, the UE includes the authorization token as binding 
information in the request. To map media flows to PDP contexts correctly, the UE 
should also include one or more flow identifiers according to the SDP description. 

1 0 (The authorization token was sent (610) by the P-CSCF/PCF to the UE during SIP 
signaling, and the flow identifiers were derived by the UE according to the 
sequence of media flows in the SDP.) A flow identifier only needs a small number 
of bits, so there will be minimal impact on airlink performance. Specifically, binding 
information is included in PDP Context Activation/Modification messages to 

1 5 associate the PDP context bearer with policy information. The PDP Configuration 
Options parameter (an optional parameter signalled in a PDP Context 
Activation/Modification request) is used for this purpose. Alternatively, another 
parameter is used, such as a Traffic Flow Template parameter of a PDP context. 
The authorization token is unique across PDP contexts associated with an 

20 APN, and conforms to the IETF specification on SIP Extensions for Media 
Authorization. 

The flow identifiers identify the IP media flows associated with the SIP 
session. As described above, flow identifiers may be based on the ordering of 
media flows in the SDP description. In this case, a flow identifier combined with the 
25 authorization token is sufficient to uniquely identify an IP media flow, since flow 
identifiers are interpreted relative to an authorization token. 

In order to allow QoS and policy information to be "pulled" from the PCF, the 
authorization token may also allow the GGSN to determine the address of the PCF 
to be used. 

* 

30 The GGSN receives (620) the PDP context request and processes the PDP 

context request. For example, the GGSN identifies (630) the IP media flow(s) 
associated with the PDP context bearer using the included binding information, 
queries (640) the PCF for the policy information to apply to the IP media flow(s) 
identified by the binding information, and uses received policy information 
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associated with the IP media flow(s) to authorize (650) the bearer, if appropriate in 
view of the policy information. 

SIP session modification can result in changes to the SDP description, such 
as the addition or deletion of media flows. (For example, in one implementation, 
5 when a media flow is deleted, the corresponding "m" line is still be in SDP 

i 

description, which will be set to u m=0". The corresponding authorized QoS resource 
for this deleted flow is set to zero in the PCF. When a new media flow is added, it 
is added at the end of the existing SDP description.) The P-CSCF/PCF may issue 
a new authorization token when the SDP description changes. If the resources 
1 0 associated with a PDP context increase as a result of the SIP session modification, 
the UE sends a PDP context modification with the old (or new) authorization token 
and flow identifiers. 

Having described and illustrated the principles of my invention with 
1 5 reference to certain described embodiments, it will be recognized that the described 
embodiments can be modified in arrangement and detail without departing from 
such principles. It should be understood that the programs, processes, or methods 
described herein are not related or limited to any particular type of computing 
environment, unless indicated otherwise. Various types of general purpose or 
20 specialized computing environments may be used with or perform operations in 
accordance with the teachings described herein. Elements of the described 
embodiments shown in software may be implemented in hardware and vice versa. 

In view of the many possible embodiments to which the principles of my 
invention may be applied, I claim as my invention all such embodiments as may 
25 ' come within the scope and spirit of the following claims and equivalents thereto. 
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CLAIMS 

I claim: 

1. In an apparatus, a method of requesting resource authorization comprising: 
transmitting one or more PDP context requests including binding information for 

5 one or more IP media flows of a session, wherein the binding information includes an 
authorization token and one or more IP media flow identifiers. 

2. The method of claim 1 wherein the one or more IP media flow identifiers 
combine with the authorization token to identify the one or more IP media flows. 

10 

3. The method of claim 1 wherein the apparatus is user equipment, and 
wherein the one or more IP media flow identifiers reference a flow order in a SDP 
description that is accessible to the user equipment and a P-CSCF/PCF. 

1 5 4. The method of claim 1 wherein each PDP context request is a PDP context 

activation request or a PDP context modification request. 

5. A computer-readable medium having encoded therein computer-executable 
instructions for causing a computer programmed thereby to perform the method of 

20 claim 1 . 

6. In a network node, a method of authorizing resources comprising: 
processing binding information for one or more IP media flows of a session, 

wherein the binding information includes an authorization token and one or more IP 
25 media flow identifiers. 

7. The method of claim 6 wherein the one or more IP media flow identifiers 
combine with the authorization token to identify the one or more IP media flows. 

30 8. The method of claim 6 wherein the network node comprises a P-CSCF/PCF, 

and wherein the one or more IP media flow identifiers reference a flow order in a SDP 
description that is accessible to the P-CSCF/PCF and user equipment. 
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9. The method of claim 6 wherein the processing comprises authorizing the 
one or more IP media flows according to a service-based local policy decision. 

5 10. A computer-readable medium having encoded therein computer- 

executable instructions for causing a computer programmed thereby to perform the 
method of claim 6. 

1 1 . A computer-readable medium having encoded therein computer- 

1 0 executable instructions for causing user equipment programmed thereby to perform a 
method of requesting resource authorization and allocation, the method comprising: 
receiving a media authorization token; and 

transmitting a context activation request including the media authorization token 
for authorizing each of one or more media flows of a session, wherein the media 
1 5 authorization token in combination with a media flow identifier from among plural media 
flow identifiers is sufficient to uniquely identify a media flow from among plural media 
flows of the session. 

12. The computer-readable medium of claim 1 1 wherein the plural media flow 

i 

20 identifiers reference a flow order in a session description, and wherein a gateway node 
authorizes the one or more media flows according to a service-based local policy 
decision. 

13. The computer-readable medium of claim 1 1 wherein the method further 
25 comprises: 

receiving a second media authorization token; and 
transmitting a context modification request including the second media 
authorization token for modifying authorization of the one or more media flows. 

30 14. A computer-readable medium having encoded therein computer- 

executable instructions for causing a network node programmed thereby to perform a 
method of authorizing and allocating resources, the method comprising: 
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receiving a context request including a media authorization token for 
authorizing each of one or more media flows of a session, wherein the media 
authorization token in combination with a media flow identifier from among plural media 
flow identifiers is sufficient to uniquely identify a media flow from among plural media 
5 flows of the session; and 

requesting policy information indicated by the media authorization token. 

15. The computer-readable medium of claim 14 wherein the plural media flow 
identifiers reference a flow order in a session description. 

10 

16. The computer-readable medium of claim 14 wherein the method further 
comprises: 

authorizing the one or more media flows according to a service-based local 
policy decision. 

15 

17. A computer-readable medium having encoded therein computer- 
executable instructions for causing user equipment programmed thereby to perform a 
method of requesting resource authorization and allocation for one or more packet 
media flows of a session, the method comprising: 

20 receiving an authorization token and packet media flow information during 

session protocol signaling, the packet media flow information accessible to a network 

node and the user equipment; and 

transmitting one or more messages including binding information for authorizing 

one or more packet media flows of a session, wherein the binding information includes 
25 the authorization token, whereby each of one or more packet media flow identifiers is 

interpreted relative to the authorization token to identify a packet media flow of the 

session. 



30 



18. The computer-readable medium of claim 17 wherein the user equipment is 
a cellular device, wherein the network node comprises a GGSN, and wherein each of 
the one or more messages is a PDP context activation or modification request. 
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19. The computer-readable medium of claim 17 wherein the one or more 
packet media flows are IP media flows. 

20. The computer-readable, medium of claim 17 wherein a SDP description 
comprises the packet media flow information, and wherein the one or more packet 
media flow identifiers reference a media order in the SDP description. 

21 . The computer-readable medium of claim 17 wherein the session protocol is 
SIP, and wherein a PCF of a P-CSCF generates the authorization token. 

22. The computer-readable medium of claim 1 7 wherein the user equipment 
transmits a single message to request resource authorization and allocation for all 
packet media flows of the session. 



15 23. A computer-readable medium having encoded therein computer- 

executable instructions for causing a network node programmed thereby to perform a 
method of authorizing and allocating resources for one or more packet media flows of a 
session, the method comprising: 

transmitting an authorization token and packet media flow information during 

20 session protocol signaling, the packet media flow information accessible to the network 
node and user equipment; 

processing one or more messages including binding information for authorizing 
one or more packet media flows of a session, wherein the binding information includes 
the authorization token, and wherein the processing includes interpreting each of one 

25 or more packet media flow identifiers relative to the authorization token to identify a 
packet media flow of the session. 

24. The computer-readable medium of claim 23 wherein the user equipment is 
a cellular device, wherein the network node comprises a GGSN, and wherein the one 
30 or more packet media flows are IP media flows. 
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25. The computer-readable medium of claim 23 wherein a SDP description 
comprises the packet media flow information, and wherein the one or more packet 
media flow identifiers reference a media order in the SDP description. 

5 26. The computer-readable medium of claim 23 wherein the session protocol is 

SIP, and wherein a PCF of a P-CSCF generates the authorization token. 

27. The computer-readable medium of claim 23 wherein the network node 
processes a single message requesting resource authorization and allocation for all 

1 0 packet media flows of the session. 

* 

28. The computer-readable medium of claim 23 wherein the method further 
comprises; 

requesting policy information indicated by the authorization token. 
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Figure 1 , prior art 
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Figure 5 
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